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Abstract 


Swift is a modern general-purpose programming language, 
designed to be a replacement for C-based languages. Al- 
though primarily directed at development of applications 
for Apple’s operating systems, Swift’s adoption has been 
growing steadily in other domains, ranging from server-side 
services to machine learning. This success can be partly at- 
tributed to a rich type system that enables the design of safe, 
fast, and expressive programming interfaces. Unfortunately, 
this richness comes at the cost of complexity, setting a high 
entry barrier to exploit Swift’s full potential. Furthermore, 
existing documentation typically only relies on examples, 
leaving new users with little help to build a deeper under- 
standing of the underlying rules and mechanisms. 

This paper aims to tackle this issue by laying out the foun- 
dations for a formal framework to reason about Swift’s type 
system. We introduce Featherweight Swift, a minimal lan- 
guage stripped of all features not essential to describe its 
typing rules. Featherweight Swift features classes and proto- 
col inheritance, supports retroactive modeling, and emulates 
Swift’s overriding mechanisms. Yet its formalization fits on 
a few pages. We present Featherweight Swift’s syntax and 
semantics. We then elaborate on the usability of our frame- 
work to reason about Swift’s features, future extensions, 
and implementation by discussing a bug in Swift’s compiler, 
discovered throughout the design of our calculus. 
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1 Introduction 


Swift is a modern general-purpose programming language, 
developed by Apple to be a successor to C-based languages. 
Often introduced in the context of mobile and desktop appli- 
cations, Swift’s adoption in other domains has been growing 
steadily since its open-source release in 2014, notably in the 
context of server-side and machine learning development. 
This success can be explained on one front by the language’s 
efficient memory model and seamless integration into the 
C ecosystem, and on another by its powerful type system. 
Swift enables the design of safe, fast and expressive pro- 
gramming interfaces by leveraging advanced features such 
as bounded polymorphism [11], existential types [31], and 
traits [19]. The latter in particular enables a discipline called 
Protocol-Oriented Programming (POP). POP is a type-driven 
paradigm that advocates for the use of protocols over con- 
crete types. Protocols in Swift are similar to interfaces in 
Java, abstract classes and concepts in C++, or traits in Scala. 
The central idea is to reason about type requirements (i.e., 
what types should be able to do) rather than properties of 
a specific implementation. Sorting algorithms are a good 
canonical use case for such an approach. Although they are 
often defined over numerical values, most sorting algorithms 
are in fact agnostic of the type of the values being sorted, 
as long as it defines a total order relation. Following that 
observation, a protocol-oriented approach consists of first 
capturing this requirement in a protocol, and then writing 
an algorithm that would rely on some existential type satis- 
fying this protocol, while remaining otherwise completely 
agnostic of any other implementation detail. 
Unfortunately, Swift's type system comes at the cost of 
complexity. While object-orientation is generally well known 
and understood by most developers, knowledge on POP pat- 
terns and related concepts is not nearly as widespread. As 
a result, exploiting the language’s full potential requires a 
high-level of expertise and experience. Furthermore, existing 
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documentation focuses on examples and does not provide 
a comprehensive overview of the type system’s rules and 
mechanisms. This impedes new users, specifically students, 
to build a deeper understanding. The lack of a formal defini- 
tion of the language’s semantics also precludes one’s ability 
to reason about its design and implementation, in particular 
to foresee interactions between different features. 

We propose to address these issues by the means of a for- 
mal framework describing Swift’s type system. We introduce 
Featherweight Swift (FS), a core calculus inspired by Feather- 
weight Java (FJ) [23]. FS captures the fundamental concepts 
of Swift’s type system and discards all features that are not 
essential to the description of its typing rules. It features class 
and protocol inheritance, supports retroactive modeling, and 
emulates Swift’s overriding mechanism, but leaves out local 
and global variables, exceptions, concurrency, and even as- 
signment. This results in a functional subset whose complete 
formalization fits on a few pages. While our approach elides 
many peculiarities, such as the difference between value and 
reference semantics [35], the bareness of the language ex- 
poses Swift’s method lookup mechanism and type coercion 
rules clearly and concisely. As a result, FS helps language 
users and designers alike to generalize assumptions and test 
them against the compiler’s implementation. 

We present Featherweight Swift’s syntax, type system, and 
operational semantics. Although we do not provide a full 
type soundness proof, we present the key properties related 
to the method lookup mechanism. We then illustrate the 
framework’s usability to reason about Swift by discussing 
one of the bugs we found in Apple’s compiler implementa- 
tion, discovered throughout FS’s formalization. The bug has 
been reported and fixed in Swift 5.2. 


2 Swift’s Type System in a Nutshell 


This section briefly introduces Swift’s type system, with a 
particular focus on its support for protocols. It is worth not- 
ing that POP solves similar problems as Object-Oriented 
Programming (OOP) [2]. However, it aims to avoid common 
pitfalls of class inheritance, such as the fragile base class 
problem [38], by advocating for composition over inheri- 
tance to keep class hierarchies as flat as possible. It also 
differs from mixin-based inheritance [9], a technique that 
consists of composing classes through multiple inheritance, 
specifically because it does not rely on inheritance as a com- 
position mechanism. Nonetheless, POP does not intend to 
replace object-orientation. Rather, it introduces features that 
can be used to refine essential object-oriented aspects, such 
as encapsulation, polymorphism, and separation of concerns. 

In Swift, a protocol represents a collection of requirements 
to satisfy. These requirements are specified in the form of 
methods to implement or properties (a.k.a. fields in Java) 
to expose. For instance, one could define a protocol that 
expresses the requirements of serializable types: 
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1 protocol Serializable { 
2 func serialize() -> String 


3 } 


The above protocol describes a type with a single method 
serialize. The method takes no argument and is expected 
to return a serialized representation of its receiver (i.e., the 
object on which it is called), as a character string. 

There are two ways to indicate that a type conforms to 
a particular protocol. The first and most straightforward is 
to specify the conformance directly within the type’s dec- 
laration and to provide an implementation for all of the 
protocol’s requirements: 


1 class Customer: Serializable { 
2 let id: String 


3 let name: String 

4 init(id: String, name: String) { 

5 self.id = id; self.name = name 

6 } 

7 func serialize() -> String { 

8 "(id:\(self.id), name:\(self.name) )" 
9 } 

10 } 


Here, the class Customer is declared conforming to the pro- 
tocol Serializable. The conformance is valid because the 
class has a method that satisfies the protocol’s requirement. 

An alternative approach, called retroactive modeling [41], 
consists of extending an existing concrete type to specify 
additional conformances and provide it with the associated 
implementations. For example, one can specify that Swift’s 
integers conform to the Serializable protocol: 


1 extension Int: Serializable { 
2 func serialize() -> String { "i(\(self))" } 


3 } 


To preserve subtyping, retroactive modeling can only add 
constructs to a type and may not modify nor remove any 
of its pre-existing characteristics. Simply put, an extension 
cannot alter any method or property from a type, nor can it 
subtract any protocol from its conformance set. 

A protocol can refine (i.e., inherit from) one or several 
other protocols to represent an aggregate of requirements. 
For instance, we can compose a protocol Doc, describing the 
requirements for types representing a document of some 
sort, with Serializable to represent persistent documents: 


1 protocol Doc { 

2 func title() -> String 

3 } 

4 protocol PersistentDoc: Serializable, Doc { 
5 func save(filename: String) 

6 


} 


Protocols may also appear in signatures to express the con- 
straints of some concrete existential type [31] satisfying their 


Featherweight Swift: A Core Calculus for Swift’s Type System 


requirements. Anonymous compositions can be created lo- 
cally when composition through inheritance does not result 
in a reusable abstraction: 


1 let doc: Serializable & Doc 


Unlike Java interfaces, protocols may refer to the concrete 
type that conforms to them. For instance, consider a protocol 
Orderable describing types with a total order: 


1 protocol Orderable { 

2 func lesser(other: Self) -> Bool 

3 } 
This protocol requires a single method lesser, that should 
return whether another instance is smaller than the receiver’. 
Notice the use of the type Self (a.k.a. MyType in related liter- 
ature [10]), that serves as a placeholder for the conforming 
type. This allows a protocol to specify methods that are not 
compatible with other types conforming to the same proto- 
col, which contributes to a stronger type safety. Indeed, the 
use of Self guarantees that two values of non-related types 
(e.g., a number and a string) cannot be compared, even if both 
types conform to the protocol Orderable. In other words, if 
a type T conforms to the protocol Orderable, then it should 
contain a method lesser with the type T — Bool. Conse- 
quently, the method will not accept a value of type U, even 
if U also conforms to Orderable. This solves a common pit- 
fall referred to as the binary method problem [10]. However, 
protocols with self requirements (i.e., defining a method or 
property requirement annotated with Self) cannot be used 
to type an expression in a protocol composition. The reason 
for this limitation is linked to the type safety guarantee we 
have just discussed. Should it be possible to type a variable x 
with the protocol Orderable, then there would be no way to 
type-check a call to the method x. lesser statically. There 
are workarounds, like explicit parameterisation (e.g., Haskell 
type classes and C++ concepts), multiple dispatch [13] or 
type erasure [14], but an extensive discussion about such 
techniques is beyond the scope of this paper. 

Swift supports protocol extensions as well. While such 
extensions cannot add additional conformances to a protocol, 
they can be used to provide additional methods and/or de- 
fault implementations for a protocol’s method and property 
requirements. The reader will remark that this feature is akin 
to the concept of partially implemented traits in languages 
such as Scala or Rust. For example, one can define a protocol 
for equatable types which, similarly to Orderable, defines 
method requirements to check for equality between two in- 
stances’. Based on this description, a default implementation 
of a method notEquals is obvious, and can be provided in a 
protocol extension. 


Note that the requirement is purely syntactical and does not prescribe 
anything about the method’s semantics. 

°The reader proficient in Swift will notice that this definition of 
Equatable differs from Swift’s built-in protocol. This choice is delib- 
erate and made to brush over the notion of static function requirements. 
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1 protocol Equatable { 
2 func equals(other: Self) -> Bool 

3 } 

4 extension Equatable { 

5 func notEquals(other: Self) -> Bool { 
6 !self.equals(other: other) 

7 


8 } 

Conforming types may still override default implementa- 
tions, typically to provide optimized alternatives that can 
rely on the properties of the conforming type. Otherwise, 
they will inherit all default implementations. One problem re- 
lated to this feature occurs when two distinct protocols have 
implementations for the same method requirement. This in- 
troduces an ambiguity for conforming types, which must 
specify which implementation should be inherited. There 
exists a handful of techniques to handle these cases [33]. 
However, in Swift, conflicts can only be resolved by overrid- 
ing the default implementation in the conforming type, as 
of this writing. Consider the following example: 


1 protocol Dumpable { 
2 func dump() 


3 } 


4 extension Dumpable { 


5 func dump() { print("Some Dumpable val.") } 
6 } 

7 

8 protocol Doc { 

9 func title() -> String 

o } 

1 extension Doc { 

2 func dump() { print(self.title()) } 

B } 

14 

15 class DummyDoc: Dumpable, Doc { 

16 func title() -> String { "A document" } 

17 func dump() { print("Some DummyDoc val.") } 
is } 

9 


N 
© 


DummyDoc ( ) .dump ( ) 
21 // Prints "Some DummyDoc val." 


The class DummyDoc conforms to Dumpable and Doc, and ob- 
tains two default implementations for dump, defined at line 
5 and 12 respectively. Hence, it must solve the conflict by 
overriding the method, which is done at line 17. 

Notice that protocol extensions can provide implemen- 
tations even when they are not defined as requirements. 
This is the case in the above example. The method dump 
is provided by an extension at line 12 even if the protocol 
Doc does not require it. This results in a subtle difference in 
the lookup mechanism, reminiscent of non-virtual methods 
in C++ [4], that allows the compiler to dispatch methods 
statically. Hence, if the dump is called on an existential type 
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satisfying Doc only, the implementation declared at line 12 


will be called even if it is reimplemented in the concrete type. 


This behavior is specific to protocol extensions and cannot 


be reproduced with concrete types. It is not formalized in FS. 


3 Featherweight Swift 


Featherweight Swift is a strict functional subset of Swift, 
which focuses on the latter’s essential features to describe 
its type system. A program is described by a set of classes, 
protocols and extensions, and a single expression. The latter 
represents the behavior of the entire program. 


protocol Thing { 
func duplicated() -> Pair 


} 


func duplicated() -> Pair { 
Pair(fst: self, snd: self) 


1 
2 

3 

4 

5 extension Thing { 
6 

7 

8 

9 

0 

1 class A: Object, Thing {} 
2 

3 


class B: Object, Thing { 
4 let foo: A 


21 class Pair: Object { 
22 let fst: protocol<Thing> 


23 let snd: protocol<Thing> 

24 func withFst(v: protocol<Thing>) -> Pair { 
25 Pair(fst: v, snd: self.snd) 

26 } 

27 } 

28 

29 Pair(fst: A(), snd: B(foo: A())) 

30 .snd 

31 .duplicated() 

32 -withFst(C(foo: A(), bar: A())) 


33 // Evaluates to "Pair( 
34 // fst: C(foo: A(), bar: A()), 
35 // snd: B(foo: A()))" 


Figure 1. A typical Featherweight Swift program 


From Swift, FS keeps protocols, extensions and classes, 
and its type system supports protocol conformance, protocol 
composition, and class inheritance. However, among Swift’s 
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most common features, FS drops non-member functions and 
properties (i.e., functions and variables declared outside of 
a class), computed properties, exceptions, concurrency, and 
side effects. All properties are considered to be let (a.k.a. 
constant) bindings, assigned only once in their class’ ini- 
tializer, and method arguments cannot be reassigned. We 
also elide the difference between value and reference types, 
whose respective observable behaviors are indistinguishable 
in the absence of side effects. Despite all these omissions, 
FS remains expressive enough to be Turing complete (one 
can encode the A-calculus in FS). Note that FS does not fea- 
ture generic types. While these account for a significant part 
of Swift’s type system, we prefer to focus solely on class 
inheritance and protocol conformance. 

Figure 1 illustrates an example of a FS program. It starts 
with the declaration of a protocol Thing, which contains a 
single requirement for a method duplicated. It is extended 
at line 5 to provide a default implementation for its unique 
requirement, which consists of initializing a new instance of 
the class Pair using the method receiver for both elements. 
The program declares four classes, A, B, C and Pair at lines 
11, 13, 17 and 21 respectively. A and B inherit from a built-in 
root class Object and conform to the protocol Thing, but 
B additionally declares a property foo, which is inherited 
by the class C. Pair declares two properties fst and snd, 
along with a method withFst that returns a copy of itself 
in which the first element is substituted with the method’s 
argument. The use of these types is finally illustrated by the 
expression at line 29, which initializes a pair, duplicates its 
second element to produce another pair, and substitutes its 
first element with an instance of the class C. 


3.1 Formal Syntax 


Let C denote a syntactic category, we write C* for a possibly 
empty set of syntactic constructions that are generated by C. 
Similarly, let S be a set, we write S* C P(S). 


Definition 3.1 (Featherweight Swift’s syntax). Let I, de- 
note the set of protocol identifiers, Ie denote the set of class 
identifiers and Iy denote the set of variable, property, and 
method identifiers. Let the metasyntactic variable p range 
over Ip. Let c and d range over Ic, and x range over Iy. FS’s 
syntax is described as follows: 


Prog. II Pd* Cd" Xd* e 
Prot. Pd “= protocolp: p { Rd* } 
Class Cd == classe: d,Ij { Vd* Md" } 
Ext. Xd := extension p { Md* } 
| extensionc: I% { Md" } 
Prop. Vd := letx:t 
Meth. Md := funex(x,:%%,...,%:T™) >T{e} 
Req. Rd := funcx(x1:T1,...,Xn: Tn) >T 
Expr. e == xlex|eastl|leas! rt 
| e(ei,..., €n) | C(x : e1,...,Xn : en) 
Type T = c|protocol(I$} | 7 — 7 | Self 
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FS’s syntax is defined to be as close as possible to that of 
Swift. In fact, FS programs can almost be copy-pasted into 
a Swift compiler and have the same semantics. We assume 
that a program does not contain duplicate type declarations. 
Similarly, we assume that classes do not contain duplicate 
property or method declarations and that methods do not 
feature duplicate parameters. 

A protocol declaration protocol p : P { R } declares a 
protocol p that refines each of the protocols in P. The decla- 
ration’s body is a set of method requirements (i.e., methods 
that conforming types should implement), which are de- 
clared the just as regular methods, except that they do not 
have a body. For simplicity, we omit property requirements. 
These would require the addition of computed properties 
(i.e., properties whose values are the result of a method call), 
whose typing mechanism overlaps with regular methods. 

A class declaration class c : d,P { V M } introduces a 
class named c that inherits from a base class d, and conforms 
to each of the protocols in P. All class declarations define a 
supertype, for the sake of syntactic regularity. Consequently, 
classes that in standard Swift do not inherit from any base 
class are declared inheriting from a root class Object in FS°. 
The body of a class declaration consists of a set of property 
declarations and a set of method declarations. Since the lan- 
guage is free of side effects, all properties can be treated 
as let (a.k.a. constant) bindings. In other words, all prop- 
erty declarations are of the form let x : t, where x is the 
name of the property being declared and T is its type, and 
we omit default values. FS does not support overloading, 
including for initializers. Thus, all classes necessarily have a 
single memberwise initializer (i.e., an initializer that accepts 
an argument for each of the class’ properties), which we 
keep implicit for conciseness. Unlike in Swift, nested classes 
(a.k.a. inner classes in Java) are prohibited. While such a fea- 
ture can serve to declutter the global namespace, it does not 
contribute to expressiveness. Furthermore, we also omit cus- 
tom deinitializer (a.k.a. destructors), as those cannot affect a 
program’s behavior in the absence of side effects. 

An extension declaration of the form extension p { M } 
is called a protocol extension. It provides a protocol p with 
method implementations for its conforming types. Similarily, 
an extension of the form extension c : P { M } is called 
a class extension. It can provide a class c with additional 
protocol conformances and method implementations. 

A method declaration func x(x; : t4, ..., Xn : Tn) > T{e} 
declares a method x that accepts n parameters and always 
returns a value, computed by evaluating the expression e cor- 
responding to the method’s body. A method’s body can refer 
to a special variable self € Iy that identifies the method’s 
receiver and allows recursion. It is treated as a regular vari- 
able rather than a keyword, so that no additional typing or 
evaluation rule is required to describe property accesses. We 


3Such a root class does not exist in actual Swift, but can be easily reproduced. 
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omit static and class methods, as well as non-member func- 
tions (i.e., functions declared outside of a class). Methods are 
first-class citizen in FS. Therefore, they must be treated as 
standard expressions (e.g., as arguments or return values), 
and an application of the form e(e1,...,e,) may feature any 
kind of expression for e. An application whose receiver is a 
class identifier (i.e., c(x1 : €61, ..., Xn : €n)) denotes a call to 
the latter’s implicit initializer. In Swift, while all initializer 
and method parameters are positional, they must also be 
named at the call site by default, unless defined otherwise 
explicitly. However, as of this writing, parameter names are 
actually not part of a method’s type. This means that a func- 
tion assigned to a variable, or passed as a parameter, cannot 
be called with named parameters. We adopt a more consis- 
tent approach in FS. In order to avoid determining an order 
on property declarations and inheritance thereof, we always 
require parameters to be named in calls to a class’ implicit 
memberwise initializer. On the other hand, parameters to 
method calls are kept positional only. 

We distinguish two sorts of cast expressions: e as T is 
called a guaranteed cast and e as! Tis called a forced cast. FS’s 
typing rules ensure that a guaranteed cast cannot trigger an 
error at runtime, whereas such an assumption is not verified 
statically for forced casts. We elide Swift's safe casts (i.e., 
expressions of the form e as? t in Swift), as they involve 
generic option types (a.k.a. the maybe monad [32]), which 
are not supported in FS. 

An expression can be typed by a class, a protocol compo- 
sition (i.e., a set of protocols), a function type, or the special 
type variable Self. The reader proficient in Swift will remark 
the use of a legacy syntax for protocol composition, which 
consists of a set of protocol identifiers enclosed in angle 
brackets and prefixed by the keyword protocol. While no 
longer supported, this syntax lets us express the empty com- 
position protocol<> which corresponds to Swift’s built-in 
Any type (i.e., an existential type without any requirement). 
A method or property may refer to the type in which it is 
declared, allowing the declaration of self-referencing types. 
In protocol declarations and extensions, the special type vari- 
able Self designates the concrete conforming type. In class 
declarations and extensions, Self designates any derived 
type that can inherit from the class: 


1 class Parent: Object { 
func identity() -> Self { self } 


N 


aes 
4 class Child: Parent {} 


The type of the method identity depends on that of the 
receiver. If the method is called on an object of type Parent, 
then the result will be an instance of Parent. On the other 
hand, if it is called on an object of type Child, then the result 
will be an instance of Child. We elaborate further on the 
reasons for this subtlety later. 
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3.2 Typing Semantics 


We now describe FS’s typing semantics. We start by in- 
troducing some notation to help formalizing predicates on 
declarations more concisely. Let z € II be a program, we 
write m + protocol p : P {R } to denote that the proto- 
col p’s declaration is part of the program x. Similarly, we 
write m + class c : d,P { V M } for class declarations, 
mx + extension p { M } for protocol extensions and m + 
extensionc : P { M } forclass extensions. We use letters dec- 
orated with a tilde symbol (i.e., ~) to denote declarations. Let 
dbea protocol, class, property, method or method require- 
ment declaration, we write d.name for its name and d.type 
for its type. For example, let m = func m(x : t) > a {e}, 
m.name = mand m.type = T > o. 


Definition 3.2 (Signature equivalence). Let m, and mz be 
two method or method requirement declarations. We say 
that they are signature-equivalent, written m, ~ mz, if their 
names and type signatures are identical. More formally: 


m xm — > m.name = mz.name A m,.type = m2.type 


Definition 3.3 (Class inheritance). Let c and d denote two 
classes in a program 7, we write m + c < d if c inherits 
from d in z. Class inheritance is the reflexive and transitive 
closure of the immediate subclass relation specified in class 
declarations. In formal terms, let c, d and e be class identifiers, 
< is the minimal relation such that: 


mrke<d mtd<e 


TrEce<ec wre<se 


x+ classc:d,P{VM} 


mteeo<d 


Definition 3.4 (Protocol conformance). Let p and q denote 
two protocols in a program x, we write 7 + p E qif p 
conforms to (i.e., inherits from) q in x. Similarly, let c denote 
a class, we write 7+ c E q if c conforms to q in x. Protocol 
conformance (i.e., E) is the reflexive and transitive closure 
of the immediate conformance relations declared in protocol 
and class declarations, as well as class extensions. In formal 
terms, let p, q and r be protocol identifiers, and c and d be 
class identifiers, E is the minimal relation such that: 


mat protocolp:Q{R} qEQ 


mtpEp r-pEq 
mr rpEq merger mte<d mtdlp 
amrper mrkelp 


mt classc:d,P{VM} 
qEP 


x+ extensionc:P{M} 
qEP 


mrclg 


mrclqg 
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Example 3.5 (Protocol inheritance). Let 2 be a program 
defined as follows: 


protocol P {} 
protocol Q: P {} 
protocol R {} 

class C: Object, Q {} 
class D: C, R {} 

D() 


From z, we can deduce that 7+ QE Pandzt DEP. 


nu BF WN 


Definition 3.6 (Conformance set). Let t be a protocol or 
class in a program z. We write conf (t, 7) for the set of pro- 
tocols to which t conforms in x. More formally: 


conf (t,x) ={pel,| a+r p} 


Example 3.7 (Conformance set). Let r be the program il- 
lustrated in Example 3.5. program defined as follows: From 
m, we can deduce that conf (D, m) = {P, Q, R}. 


Both the subtyping and the conformance relations allow us 
to define polymorphic substitutability, which is referred to as 
type coercion in Swift. This is a purely syntactical application 
of Liskov’s substitution principle [29]. 


Definition 3.8 (Coercion). Let t and o be two types in a 
program x. We write z+ t < ø if t can be coerced into o in 
z. In more formal terms, let t and o denote two types and 
let c be a class identifier, coercion is defined as the minimal 
relation such that: 


Vi, TF oj JT; It Ty SO, 
TFTAIT T F Tiss Tn ~ T I Olseccs0n — Or 
THFT VpeP,clp 
mtETS mt c < protocol(P) 


VpeP,AqeQartplg 


m+ protocol(P) < protocol(Q) 


Example 3.9 (Coercion). Let z be the program illustrated 
in Example 3.5. program defined as follows: From z, we can 
deduce that the following relations hold: 


z+ (C,C —> D) < (D,C > C) z+ C< protocol/) 


m+ protocol(Q, R) < protocol(P, R} 


3.2.1 Name Lookup. We define a function props that ac- 
cepts a class and returns the set of properties available in 
that class. Note that props does not need to check extensions 
nor conformed protocol, as these may only define additional 
methods in FS. 


props(Object, z) = Ø 


x+ classc:d,P{V M} 
props(c,z) = V U V’ 


props(d, z) = V’ 
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We define a function lookup, that returns the set of the prop- 
erty declarations with the given name in the given class: 


v € lookup,(x,c,1) & VTE props(c, m) Av.name = x 


Example 3.10 (Property lookup). Let m be a program de- 
fined as follows: 


1 class C: Object {} 

2 class D: C { let foo: C} 

3 class E: D { let bar: D} 
E(foo: C(), bar: D(foo: C())) 


We can deduce that props(E, z) contains let foo : C and 
let bar : D. It follows that lookup( foo, D, z) = {let foo : C}. 


Both class inheritance and protocol conformance con- 
tribute to FS’s method lookup mechanism. The methods 
that are associated with a class can be defined in the class’ 
declaration itself, in the declaration of another class from 
which it inherits, in extensions of the class, or even in exten- 
sions of the protocols to which the class conforms. While FS 
does not support method overloading, it allows overriding. 
A method declared in a class can be overridden in any of its 
derived classes. Furthermore, methods required in a protocol 
and implemented in an extension are meant to define a de- 
fault behavior for all conforming types, and may therefore be 
overridden as well. Method lookup is thus performed along 
two dimensions. The first and most straightforward relates 
to the class hierarchy. A method’s declaration is searched 
starting from the most derived class and climbing up through 
each superclass. Note that methods in class extensions are 
interpreted as being part of the class declaration and be- 
long to the class hierarchy. The second dimension relates to 
protocol conformance. If a method’s declaration cannot be 
found within the class hierarchy, it is searched within the 
extensions of the protocol to which the class conforms. 

Figure 2 illustrates different scenarios of method inheri- 
tance and overriding. The protocols P, Q and R are all associ- 
ated with a single default implementation for a method foo, 
defined in protocol extensions at line 5, 10 and 15, respec- 
tively. The protocol P additionally requires that conforming 
types implement a method han, as indicated by the method 
requirement declared at line 2. Note also that the protocol R 
inherits from both the protocols P and Q. The class A has only 
one method, bar, defined directly in the class’ declaration, 
at line 19. This method is inherited by the class B through 
the traditional class inheritance mechanism. In addition, the 
class B has a method han, declared at line 23, which satisfies 
the method requirement of the protocol P, whose confor- 
mance is declared at line 22. By the same conformance, the 
class also inherits the default implementation for the method 
foo, declared at line 5. The class C1 has three methods foo, 
bar and ham. However, the two former are overridden in 
the class’ declaration, at line 27 and 28, respectively’. Note 


4Swift demands that overridden methods be explicitly prefixed with the 
keyword override. We omit this requirement for the sake of conciseness. 
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1 protocol P { 

2 func ham() -> B 

3 } 

4 extension P { 

5 func foo() -> A { A() } 
6 } 

7 

8 protocol Q {} 

9 extension Q { 

0 func foo() -> A { B() } 
u } 

12 

13 protocol R: P, Q {} 

4 extension R { 

5 func foo() -> A { C1() } 
6 } 

7 

18 class A: Object { 

9 func bar() -> A { A() } 
20 +} 

21 

22 class B: A, P { 

23 func ham() -> B { B() } 
24 } 

25 

26 class Cl: B, Q { 

27 func foo() -> A { C1() } 
28 func bar() -> A { C1() } 
29 } 

30 


31 class C2: B, Q, R {} 

32 extension C2 { 

33 func qux() -> A { C2() } 
34 } 


Figure 2. Examples of method overriding 


that the method foo must be overridden. The choice of its 
implementation would be ambiguous otherwise, as class C1 
inherits the default implementations of both the protocols P 
and Q. This is not the case for the class C2. The class conforms 
to the protocol R and thus inherits the latter’s default im- 
plementation, declared at line 15. The latter overrides those 
associated with the protocols P and Q, since R refines both of 
them. The class C2 also declares the method qux, but in an 
extension at line 33, rather than directly in its declaration. 
Let M,N € P(Md) U P (Rd) be two sets of method and 
method requirement declarations. We write N > M the 
union of M with N subtracted by the declarations in M that 
have a signature-equivalent declaration in N. More formally: 


N>M={meM|fneN,m~nt}uNn 
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We define a function xmeths that accepts a protocol or class 
and gathers all methods declarations from its extensions. 
For instance, let z be the program shown in Figure 2, then 
xmeths(R, z) = {func foo() > A { C1() }}. More formally, 
let r denote a protocol or a class in a program , xmeths(t, 7) 
is the minimal set such that: 


x+ extension rt { M} x+ extensiont: P{ M} 


M © xmeths(t, 7) M C xmeths(t, 2) 


We then define a function pmeths that accepts a protocol and 
gathers all method requirements and default implementa- 
tions that are either associated directly with this protocol, 
or inherited from another protocol higher in its hierarchy. 
For instance, let z be the program shown in Figure 2, then 
pmeths(R, x) = {func foo() — A { C1() }, func ham() > 
B}. More formally, let p denote a protocol in a program 7, 
pmeths(p, 7) is defined as the set such that: 


a+ protocolp:Q{R} 
CS = conf (p, x) — {p} 


M = xmeths(p, 2) 


Mcs = U pmeths(q, 7) 
qECS 


pmeths(p, 2) = (M > R) > Mcs 


Note that pmeths does not apply overriding between proto- 
cols that do not have a conformance relationship. In other 
words, if two protocols q and r belong to the conformance 
set of some protocol p in a program z such that neither 
atqCrnoratrC q, then all requirements and default 
implementations of q and r are inherited by p, even if they 
have the same signature. This is why foo must be overridden 
by the class C1 in the program shown in Figure 2. We show 
later how FS’s type system checks that ambiguous method 
references are rejected in a well-typed program. 

Similarly to pmeths, we define a function cmeths that ac- 
cepts a class and gathers all methods and method require- 
ments that are declared directly in the class’ declaration, or 
its extensions, or inherited from a superclass, or inherited 
as a default implementation from a conformed protocol. We 
decompose the lookup process into three steps. First, let c be 
a class in a program 7, we write cmethso(c, 2) for the set of 
methods declared directly within its declaration and exten- 
sions. For instance, let z be the program shown in Figure 2, 
cmethso(B, 7) is a singleton containing the method ham’s dec- 
laration. More formally, cmethsp is defined as follows: 


x+ classc:d,P{VM} 
cmethso(c, 1) = M U xmeths(c, 7) 


Next, we write cmeths,(c, x) for the set that also includes 
the declarations inherited from superclasses. For instance, 
cmeths,(B, 7) contains the declarations for ham and bar, in- 
herited from the class A in the program shown in Figure 2. 


mt classc:d,P{...} 


cmeths,(c, m) = cmethso(c, 2) >> cmeths,(d, 7) 
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Finally, we write cmeths(c, 2) for the set that also gathers 
the implementations associated with conformed protocols: 
CS = conf (c, 2) 

Mx = U xmeths(q, 7) M = cmeths,(c, 2) > Myx 

qECS 
M’ = {m[Self > c] | m € M} 


l 


cmeths(c, z) = M 


Recall that methods defined in the class hierarchy take prece- 
dence over method requirements and default implementa- 
tions, even if the conformance is not defined on a super- 
class. More formally, if a declaration m, appears in a class 
c or any superclass d such that 2 + c < d, and a protocol 
q € conf (c, x) defines a requirement or default implementa- 
tion Mg then Mme % Mg => Mg ¢ cmeths(c, 2). Moreover, 
notice that cmeths substitutes references to Self by the class 
for which it builds the set of methods. For instance, if a 
class c conforms to a protocol with a default implementation 
func foo(x : Self) — Self { x }, then it will be transformed 
as func foo(x : c) — c { x } in cmeths(c, 2). We define a func- 
tion lookup,,, that returns the set of methods and method 
requirements with the given name in the given class: 


lookup, (x, c, x) = {m € cmeths(c, 2) | m.name = x} 


Similarly, we define a function lookup, that returns the set 
of method requirement and default implementations with 
the given name in the given protocol: 


lookup „m(x, p, 1) = {m € pmeths(p, x) | m.name = x} 


Example 3.11 (Method lookup). Let z be the program in 
Figure 2. The set cmethso(C2, 2) of methods declared within 
C2’s declaration contains only func qux() — A { C2() }. The 
set cmeths, (C2, 7) that also includes the methods declared 
in C2’s class hierarchy additionally contains func ham() > 
B { B() } and func bar() — A { A() }. Finally, the set con- 
taining the four methods available to the class C2 is given 
by cmeths(C2, m) = {func ham() — B { B() }, func bar() > 
A{C2() }, func foo() — A{C1() }, func qux() — A{C2() }} 


3.2.2 Type Checking. The typing rules for expressions 
are presented in Figure 3. All rules are described in the form 
of a typing judgment x,IT + e : t, where z is a program, T 
is a mapping from variable identifiers to types, e is an ex- 
pression and 7 is the type of the expression. We draw the 
reader’s attention on a few subtleties. The rules TE-CProp 
and TE-CMeru correspond to the typing of a class member 
selection (i.e., a property or a method). Recall that lookup, 
and lookup,,,, returns sets of declarations. Consequently, the 
rules check that there is at least one candidate. However, it 
does not ensure that this candidate is unique, which could 
lead to ambiguous situations. Fortunately, this cannot hap- 
pen in a well-typed program because the typing rule for 
class declaration (described later) ensures that class mem- 
bers are not overloaded. The same assumption does not hold 
for protocol compositions (i.e., a protocol composition can 
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TE-GCastT TE-FCastT TE-CPRopP TE-CMETH 

TE-VaR mr e:o m,Tbke:o m,Tre:c m,lre:c 

tT =I (x) TOAT inst(t, 2) TFTA inst (t, 2) v € lookup,(x, c, 2) m € lookup,m(x, c, 7) 
mU0Kx:T m,0 + (€ast):T m,0 + (eas! t):T m, T + e.x: v.type x, IT + e.x: m.type 

TE-PMETH 

m,T + e : protocol(P) TE-CALL TE-INIT 
{m} = U lookup „m(x, p, 7) mI be: (%],...;T) OT props(c, 2) = {01, .. ., Un} Vi, 2,T + e; : ci 
peP Vi, x, I + ei : 0; Vi, TH oj IT; Vi, 0j.name = x; A T H oj < 0;.type 
m, T + e.x : m.type m,T + e(€y,...,€n) iT m,T H (xy : €y,..-,Xn 2 en) iC 


Figure 3. Featherweight Swift’s expression typing 


be associated with overloaded symbols). As a result, the rule 
T-PMETH must also check for the candidate’s uniqueness. 

A cast is statically “guaranteed” (TE-GCasr) if the type of 
the expression to cast can be coerced into the specified type. 
On the other hand, a cast whose specified type is a subtype of 
the expression’s type cannot be type-checked statically, and 
is therefore dubbed “forced” (TE-FCast). Note that casting 
between completely unrelated types (i.e., a pair t, ø such that 
neither z+ T < onor 7 + o < T) necessarily results in a type 
error. Recall that protocols with self requirements cannot 
be used to type an expression, due to the binary method 
problem [10]. Hence, casting rules must also ensure whether 
the specified type is instantiable, which is performed by 
checking a predicate inst, formally defined as follows: 


a+ protocol p,O {R} 
Vq € Q, inst(q, 2) 
Vr € R, inst(r.type, 7) 


inst(p, 2) 


mt classc:d,P{... } 
inst(d, 7) 


inst(c, 0) 


Vq € P, inst(q, 7) 


inst (Object, 7) inst(protocol(P), 7) 


Vi € {0,...,n}, Ti # Self A inst (ti, 2) 


inst(t,...,;T — To, 2) 

The type-checking rules are presented in Figure 4. Typ- 
ing a program (TD-Procram) consists of type-checking all 
its declarations as well as the expression that represents its 
behavior. Type-checking for class declarations guarantees 
that all the requirements from the protocols to which the 
class conforms are actually fulfilled. Notice that protocol con- 
formance is not a structural property. In other words, even 
if a class c has an implementation for all the method require- 
ments in p, c = p does not hold unless p is explicitly defined 
as a protocol to which c must conform (i.e., p € conf (c)). We 
write impls(c) © cmeths(c) the set of complete method dec- 
larations associated with c, that is the set of declarations that 
have a body, and define conformance checking as follows: 


Definition 3.12 (Protocol conformance checking). Let c be 
a class and p a protocol in a program z such that t+ c E p. 
We say that c satisfies its conformance to p, written 2 + c E p, 
if it has a single implementation for each of the method 
requirements defined by p and the protocols from which p 
inherits. More formally, E is the minimal relation such that: 


merce p mt protocolp:Q{R} 
Vr € R, Alm € impls(c),m x T 
Vq € conf (p,m) - phr c Hq 
mekcEp 


Type-checking for method declarations is described by 
TD-PMetH and TD-CMeEtTu, which determine whether a dec- 
laration is valid in the context of the protocol or class, re- 
spectively. Both rules verify that the type of the method’s 
body is compatible with the method’s signature. This is done 
in a fresh typing environment, in which only self and the 
method’s parameters are defined, to prevent methods from 
capturing any identifiers by closure. Recall that overriding 
does not apply to protocols’ requirements and default imple- 
mentations. Nonetheless, FS’s type system requires that all 
methods with the same name have the same signature, which 
is checked in rule TD-PMetu. The rule TD-Prorocot checks 
that the conformance set of a protocol p forms a directed 
acyclic graph rooted by p, to avoid circular inheritance. It also 
prevents protocol extensions to declare a method implemen- 
tation without a matching requirement, thus disallowing stat- 
ically dispatched methods. Class declarations additionally 
require that properties and methods cannot be overloaded. 
There should be a single implementation of each class mem- 
ber, which is checked in rules TD-CProp and TD-CMEtTu. This 
is not a requirement in TD-PMETH, as a protocol may receive 
multiple default implementations from the protocols that it 
refines. Consequently, a class that inherits multiple default 
implementations (typically obtained via different protocol 
extensions) must override them, so that method calls are 
not ambiguous. For instance, the declaration of the class C1 
in Figure 2 would no longer be well-typed if line 27 were 
commented out. 
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TD-PROGRAM TD-PROTOCOL 
Vp € P,(P,C,X,e) + p : p.name 
Ve € C, (P,C,X,e) + €: C.name 


(P,C, X,e),O te: 


Hig € conf (p, 2),q E p 
ym € xmeths(p, z), 3r € Rm xT 
Vm € pmeths(p, z), (1, p) + m : m.type 
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TD-C1ass 
Vp € conf (c, m), m H c Ep 
Vo € props(c, 7), (7,c) H U: v.type 
Vm € cmeths(c, 1), (a,c) + m : m.type 


+ (P,C,X,e):t 


TD-PREQ 
Ym € lookup „m(x, Ps m),m.type = Tı, .. 
m, p + func x(x : T%,.. 
TD-PMETH 
m, [self > p, xı Œ Tis.. -Xn Œ Tn] He: 0 TOIT 
Vm € lookup „n(x, p, m), M.type = Ti, ... Tn > T 
Xn: Tn) 2tT{e}:%,.. 


m, p H func x(x : Ti,... Tn >T 


x+ protocol p,P{R}:p 


-Tn >T 


Xn: Tn) > T: T,.. 


x+ classc:d,P{VM}:c 


TD-CPRop 
|| lookup, (x, c, x) ||= 1 
Tn OT m,ck (letx:T):T 
TD-CMETH 


|| lookup (x, c, 7) ||= 1 


z, [self > c, x1 H T%],...,Xn BP Tn] kero odt 


m,e H func x(x, : Tis... Xn: Tn) 2T{e}:%,...,;| OT 


Figure 4. Featherweight Swift’s declaration typing 


3.3 Operational Semantics 


As mentioned earlier, thanks to the omission of assignment, 
FS’s semantics can be defined purely within its syntax. How- 
ever, because methods are first-class citizens in FS, we need 
a way to represent bounded methods (i.e., methods in which 
references to self are bound to a receiver) as first-class 
terms. This is done by “demoting” a method to a non-member 
function in which all occurrences of self are syntactically 
substituted by the receiver. FS does not support unbounded 
methods: an expression of the form c.m is not well-typed if 
c € I, isaclass identifier, as we would be unable to bind oc- 
currences of self to a proper class instance. The set of values 
Y to which a terminating program may evaluate is therefore 
composed of bounded methods and class initializers only. 
More formally, it is defined inductively as the minimal set 
such that Md C Y and c(x; : 01,...,;Xn : Un) € V, where 
c € I, isa class identifier, x1, . . ., Xn € I, are property names 
and v4,...,Un € Y are values. 

We describe FS’s operational semantics as “big-step” se- 
mantics rules, with a judgement of the form z + e || v, where 
ax € II is a program, e € E is an expression and v € Y isa 
value. All rules are presented in Figure 5. Unbounded meth- 
ods are bound upon method selection by the rule E-Metu. It 
results that function calls can remain completely agnostic 
of this process, and simply substitute function parameters 
with their corresponding argument (rule E-Ca tt). 


Example 3.13. Consider the expression following expres- 
sion, defined in the context of the program shown in Figure 1: 


Pair(fst: A(), snd: B(foo: A())).snd 
. duplicated() .withFst(C(foo: A(), bar: A())) 
The following steps describe the evaluation of this expression. 


The rule E-Catt applies first to evaluate the call to the method 
withFst. This triggers the evaluation of the function’s callee, 


which happens to be another function call. 


Pair(fst: A(), snd: B(foo: A())).snd 
. duplicated() .withFst(C(foo: A(), bar: A())) 
The rule E-Catt applies again, this time to evaluate the call 
to the method duplicated. This triggers the evaluation of 
the function’s callee, which is the access class property snd: 
Pair(fst: A(), snd: B(foo: A())).snd 
. duplicated() .withFst(C(foo: A(), bar: A())) 
The rule E-Prop applies on the property selection, evaluating 
Pair(fst: A(), snd: B(foo: A())) with the rule E-Inir. 
The term remains unchanged, as it is already in reduced 
form (i.e., it only features calls to class initializers). Therefore 
E-Prop’s application produces a term B(foo: A()) (ie., the 
second element of the pair), which now acts as the receiver 
for the call to duplicated: 
B(foo: A()) . duplicated () 
.withFst(C(foo: A(), bar: A())) 


This results in the pair Pair(fst: B(foo: A()), snd: B( 
foo: A())), allowing the call to withFst to be evaluated: 


Pair(fst:C(foo: A(), bar: A()), snd:B(foo: A())) 


The program successfully terminates with this term, which 
cannot be further reduced. 


The rule E-FCast, which corresponds to the evaluation 
of an forced cast, refers to a function typeof to obtain the 
runtime type of a particular term, formally given as follows: 
.,Xn:Un)) =c 


Xn: Tn) > T) =%,.. 


typeof (c(x, : v1,.. 
typeof (func x(x; : Tı, .. TT 
The reader will notice that protocols are completely absent 
from the operational semantics, including the definition of 
the function typeof. Indeed, while protocols may be use 
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E-INIT E-PRop E-FCAST 
Vi, + e; l} vi mre el..., Xi: Uir...) mHeljv m+ typeof (v) < T 
TH C(x: &1,...,Xn : en) Y e(x1 :01,...,Xn : Un) mt e.x; |} 0; mreas! tllu 
E-METH _ E-CALL 
mre | c(v) mate) func x(x, :%%,...Xn:T)—2T{e’ } E-GCasr 
{func x(p) > T { e }} = lookup,,,, (x, c, 2) Vi, m H e; l|} vi mt e [xi +9 Ui. .., Xn > Un] Yo merely 


mt ex || func x(p) > t { e[self > c(v)] } 


mrkeastllu 


.5€n) ho 


m+ e(e,.. 


Figure 5. Featherweight Swift’s operational semantics 


to type an expression, runtime values can only be class in- 
stances and bounded methods. 


3.4 Properties 


This section presents some key properties of FS’s type system. 
The first relate to overloading and guarantees that classes 
do not define overloaded properties and/or methods in a 
well-typed program. The two first lemmas imply that there 
is a unique declaration corresponding to a name lookup in 
the rules TE-CProp and TE-CMetu, which respectively cor- 
respond to the resolution of property and method names. 
The third additionally guarantees that m be a proper method 
declaration and not a mere requirement in TE-CMETH. 


Lemma 3.14. Let c denote a class in a well-typed program 
a € TI, then c does not define any overloaded property. 


mt classc:d,P{VM} 


= Vx € ly, || lookup,(x,¢, 2) ||< 1 


Proof. The proof is straightforward by TD-Ctass. Oo 


Lemma 3.15. Let c denote a class in a well-typed program 
a € TI, then c does not define any overloaded method. 


mt classc:d,P{VM} 
= Wx € I,,|| lookup,,,(x,¢, 2) ||< 1 


Proof. The proof is straightforward by TD-Ctass. Oo 


Lemma 3.16. Let c denote a class in a well-typed program 
x € II, then all methods m € cmeths(c, 2) have an implemen- 
tation. 


z+ classc:d,P{VM} = > VYm € cmeths(c,2),m € Md 


Proof. The proof is straightforward by TD-Crass. o 


Next, we state the substitution lemmas. 


Lemma 3.17. Lett and o be two types in a well-typed pro- 
gram x such that x + t < o. The set of properties and methods 
of o is a subset of the set of properties and methods of t. 


e ift € I, ando € I, denote classes, then props(o,) © 
props(t, x) and cmeths(o, m) © cmeths(t, 1); 


e ift € I, denotes a class and o = protocol (P) is an in- 
stantiable protocol composition for some set of protocols 
P C P(Ip), then pep pmeths(p, x) & cmeths(t, x); 

e ift = protocol(P) and o = protocol(Q) are two 
protocol compositions for some sets of protocols P,Q © 


P (Ip), then qeg pmeths(q, 2)  Upep pmeths(p, 7). 


Proof. The proof is by induction on the definition of the 
coercion operator (Definition 3.8). m 


Lemma 3.18. Lete bea well-typed expression such that 2,T + 
e: T. LetI’ be typing context such thatVx € dom(T),T’(x) < 
T(x). Then 2,T’ e:t andr’ <r. 


Proof. The proof is by induction over the derivation FS’s 
expression typing (Figure 3). Oo 


FS supports recursion through self. As we chose to ex- 
press its operational semantics with big step inference rules 
(in part to sidestep the so-called stupid cast problem [23]), 
stating type soundness with the usual progress and preser- 
vation theorems [42] requires to take diverging evaluations 
into account. This disqualifies the classical approach which 
consists of defining a predicate z + e |} error to character- 
ize type errors, as it does not allow the distinction between 
well-typed programs that terminate and those that diverge. 
Another strategy is to rely on coinduction to define a relation 
of the form x + e || which denotes non-terminating evalu- 
ations [26]. Although we do not include such definitions, for 
spatial reasons, we state type soundness with this principle. 


Lemma 3.19 (Preservation). Let e is a well-typed expression 
such thatz,®+te:tandatellu,thenz,@+tv:o0 => 
o it. 


Proof. The proof is by induction over the derivation of the 
relation z+ e || v (Figure 5), using the substitution lemmas. 
m 


Lemma 3.20 (Progress). Lete is a well-typed expression such 
that m,Ø + e : t and $o, 7 + e |} v, then 7 + e I~. 


Proof (Structure). The proof is by coinduction and case anal- 
ysis over e. m 
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Theorem 3.21 (Type Soundness). Let e is a well-typed ex- 
pression such that m, + e : q, then either m + e °” or 
Fo, m + e uv. 


4 Reasoning About Swift 


The design of FS allowed us to unveil or rediscover a handful 
of bugs with the official implementation of Swift’s compiler. 
These bugs were discovered on the version 5.1.2. Three of 
them directly affect the language’s handling of protocol com- 
position. However, one relates to unbounded methods [37], 
which were supported in an earlier design of FS’s type sys- 
tem but were eventually dropped for the sake of simplicity, 
and another involves generic types [24]. The remainder of 
this section focuses on the third one [36]. 

Swift protocols may refer to the variable Self to serve as 
a placeholder for the types that conform to them. It follows 
that if Self appears in a method requirement, then conform- 
ing types must implement a method that substitutes it with 
themselves. For instance, consider the following protocol: 


1 protocol Boxable { 
2 func boxed() -> Self 


3 } 


Boxable defines a single requirement for a method boxed 
that returns instances of the conforming type. Because of 
class inheritance, there is one important caveat to consider 
when conforming to this protocol. Indeed, the following class 
declaration is not well-typed: 


1 class List: Boxable { 

2 let next: List? 

3 func boxed() -> List { List(next: self) } 
4 } 


While List satisfies Boxable’s requirements, a subclass will 
not. It will inherit a method boxed with a type () — List, 
which does not match its corresponding requirement. The 
solution is to substitute List with Self so that the method 
declaration refers to the type of the subclass. Unfortunately, 
this introduces another problem, as the type of the expression 
List(next: self) is not compatible with Self. A simple 
workaround is to force cast the expression: 


1 class List: Boxable { 

2 let next: List? 

3 func boxed() -> Self { 

4 List(next: self) as! Self 
5 } 

6 } 

7 


8 class DerivedList: List { 
9 let foo: String 
10 } 


12 print(DerivedList(foo: "bar", next: nil) 
13 .boxed ( ) . foo) 
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This program is now well-typed in both Swift and FS but 
should fail at runtime with a cast error. At line 12, the method 
boxed is invoked with a type () — DerivedList. Hence, 
Self should refer to DerivedList rather than List. It fol- 
lows that List(next: self) as! DerivedList must fail, 
because List is not a subclass of DerivedList. However, as 
of the version 5.1.2, Swift would not detect such a failure and 
happily cast an instance of List as a DerivedList, thus by- 
passing type safety. Consequently, the program would have 
an undefined behavior upon accessing the property foo on 
the value returned from the method call. 

We discovered this bug while stating FS’s progress theo- 
rem. In order to review each case of the operational semantics 
systematically, we designed a collection of use-cases to test 
various derivation scenarios and compare them to actual ex- 
ecutions to validate the result of our semantics. This eventu- 
ally led us to the above program. It turns out that the problem 
is obvious under FS’s semantics. Since List 4 DerivedList, 
the rule E-FCasr cannot apply and the derivation is stuck at 
the cast expression. 


5 Related Work 


There is a rich literature dedicated to the study of program- 
ming languages by the means of minimal core calculi, usu- 
ally building on top of the A-calculus. Unfortunately, in its 
simplest, purest form, the A-calculus is not ideal to reason 
about object-oriented abstractions, such as inheritance and 
composition. This has spawned the development of several 
calculi, including highly influential work such as Abadi and 
Cardelli’s object calculus [1] and Featherweight Java [23]. 
This work borrows heavily from the latter. FJ is a popular lan- 
guage calculus that aims to provide a sound base for studying 
extensions to the Java language. Just as FS, it discards most 
of Java’s features to focus on a minimal functional subset 
akin to the A-calculus. FS differs from FJ in three significant 
ways. The first obviously relates to protocols, which add an 
extra dimension to method lookup and type polymorphism. 
Nonetheless, intuitions about substitution lemmas remain 
identical. The second difference is that methods in FS are 
first-class citizens. As such, they may be passed as arguments 
or returned from a function, whereas Featherweight Java 
is a first-order calculus. This slightly complicates the typ- 
ing rules and operational semantics related to method calls, 
since we cannot assume that e is necessarily an expression 
of the form e.m in a method call e(e1,..., en). Lastly, FS is 
formalized in terms of a “big-step” operational semantics, 
whereas FJ is formulated using “small-step” semantics. This 
provides the calculus with a simpler model to express com- 
plex features such as concurrency and exceptions, although 
these shortcomings can be tackled by expressing properties 
on derivation at a meta-level [35]. On the other hand, this 
introduces inconsistencies in the derivation of expressions 
whose evaluation order has to be taken into account. For 
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instance, a special rule has to be defined to state the progress 
theorem with respect to failed cast expressions. 

There exist a number of theoretical work aimed at for- 
malizing protocol-oriented approaches. Traits, from which 
Swift protocols directly derive, are introduced in [39] for 
an untyped calculus [19]. The first attempt to type-check 
them statically is proposed in [20]. While their language 
offers more features than FS, including for instance property 
updates (i.e. assignments), composition is only supported 
for disjoint traits (i.e. traits without any common methods), 
and support for casting is limited. This latter limitation is 
addressed in [40]. Another paper, more closely related to 
this work, studies traits as an extension of FJ called Feath- 
erTrait [28]. While FS only relies on overriding to disam- 
biguate overlapping default implementations, FeatherTrait 
also formalizes aliasing and exclusion as composition mech- 
anisms [33]. However, traits must be type-checked every 
time they are imported into a class, whereas protocol type- 
checking only occurs once in FS, promoting modularity. This 
limitation is later addressed in [27] by treating trait compo- 
sitions as interfaces. FS adopts a similar approach, defining 
type coercion over class inheritance and protocol composi- 
tion. More recent work on calculi with traits focus on state 
(e.g. [6, 16]) and behavioral properties (e.g. [3, 17]). 

The POP discipline can be adopted in a variety of program- 
ming languages, including Scala, that shares a number of 
similarities with Swift with respect to its features and design 
choices. A formalization of Scala’s type system is presented 
in the form of a core calculus, that includes traits [15]. The 
model features a more complex lookup mechanism than FS 
to accommodate the richer, more expressive set of type con- 
structions supported by the Scala language. Typescript and 
Go are two modern languages that offer a different take on 
POP, using structural typing as a mechanism for retroactive 
modeling. This contrasts with FS, which requires protocol 
conformance to be explicitly stated in type declarations or 
extensions thereof. Both TypeScript and Go have been for- 
malized in the form of core language calculi [7, 22]. 


6 Conclusion and Future Directions 


We have presented Featherweight Swift, a core calculus to 
understand and reason about Swift’s type system. Our ap- 
proach mimics that of Featherweight Java [23]. FS drops 
all non-essential features and focuses only on the funda- 
mental concepts that characterize Swift’s type system. Our 
language comes with classes and protocol inheritance, sup- 
ports retroactive modeling, and reproduces Swift’s overrid- 
ing mechanisms. On the other hand, it discards local and 
global variables, exceptions, concurrency and assignment. 
As a result, its syntax and semantics can be defined concisely, 
in a style reminiscent of the A-calculus, and highlight Swift’s 
type coercion and method lookup mechanism clearly and 
unambiguously. 


SLE ’20, November 16-17, 2020, Virtual, USA 


We have discussed how FS served us to reason about 
Swift’s semantics, which eventually led us to the discovery 
of a few bugs. This convinces us of the necessity to provide 
language users and developers alike with a suitable formal 
framework to generalize assumptions and envision how new 
ideas may interact with existing features. The entry barrier to 
new, modern programming languages is constantly pushed 
higher, as elaborate typing mechanisms make their way into 
mainstream languages. Therefore, it is paramount that these 
be accompanied by rigorous definitions. 

This work prompts a number of exciting perspectives for 
future developments: 


e Generic types contribute significantly to the power of 
Swift’s type system, in particular when used in concert 
with protocols, and would therefore constitute a wel- 
comed extension of our work. Although the generic 
extension of FJ [23] is an obvious starting point, one 
challenge is to provide a support for Swift’s bounded 
polymorphism [11], whereas most approaches are re- 
stricted to parametric polymorphism. Fortunately, the 
more recent formalization of Go [22] provides promis- 
ing insights to tackle this issue. 

e Another natural extension would relate to the support 
of assignments. Once again, a number of extensions 
to Featherweight Java have already been proposed 
(e.g. [8, 30]). Here, the challenge is to properly repro- 
duce Swift's distinction between value and reference 
types [35]. A promising lead in that direction would be 
to adopt a similar approach as Giannini’s pure impera- 
tive calculus [21], that proposes to represent aliasing 
directly at the syntactic level. 

e A third axis relates to concurrency. Although Swift’s 

current concurrency model is based on a traditional 

multithreaded approach (for which FJ extensions have 
already been proposed [12, 34]), future implementa- 

tions will feature actors on the top of coroutines [25]. 

Hence, a formal framework to reason about such ap- 

proaches in the context of Swift’s type system would 

be of great interest. There exist multiple language 
calculi from which we can draw inspiration in that 

front [5, 18]. 

Some of the features that we have dismissed can be 

easily encoded on top of FS, but a formalization of 

these encodings has yet to be provided to validate their 
soundness. This would let us study a larger subset of 

Swift, for instance, to reason about observers, lazy, and 

computed properties. 
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